A storage system typically comprises one or more storage devices into which information may be entered, and from which information may be obtained, as desired. The storage system includes a storage operating system that functionally organizes the system by, inter alia, invoking storage operations in support of a storage service implemented by the system. The storage system may be implemented in accordance with a variety of storage architectures including, but not limited to, a network-attached storage environment, a storage area network and a disk assembly directly attached to a client or host computer. The storage devices are typically disk drives organized as a disk array, wherein the term “disk” commonly describes a self-contained rotating magnetic media storage device. The term disk in this context is synonymous with hard disk drive (HDD) or direct access storage device (DASD).
The storage operating system of the storage system may implement a high-level module, such as a file system, to logically organize the information stored on volumes as a hierarchical structure of data containers, such as files and logical units. For example, each “on-disk” file may be implemented as set of data structures, i.e., disk blocks, configured to store information, such as the actual data for the file. These data blocks are organized within a volume block number (vbn) space that is maintained by the file system. The file system may also assign each data block in the file a corresponding “file offset” or file block number (fbn). The file system typically assigns sequences of fbns on a per-file basis, whereas vbns are assigned over a larger volume address space. The file system organizes the data blocks within the vbn space as a “logical volume”; each logical volume may be, although is not necessarily, associated with its own file system.
A known type of file system is a write-anywhere file system that does not overwrite data on disks. If a data block is retrieved (read) from disk into a memory of the storage system and “dirtied” (i.e., updated or modified) with new data, the data block is thereafter stored (written) to a new location on disk to optimize write performance. A write-anywhere file system may initially assume an optimal layout such that the data is substantially contiguously arranged on disks. The optimal disk layout results in efficient access operations, particularly for sequential read operations, directed to the disks. An example of a write-anywhere file system that is configured to operate on a storage system is the Write Anywhere File Layout (WAFL®) file system available from Network Appliance, Inc., Sunnyvale, Calif.
The storage system may be further configured to operate according to a client/server model of information delivery to thereby allow many clients to access data containers stored on the system. In this model, the client may comprise an application, such as a database application, executing on a computer that “connects” to the storage system over a computer network, such as a point-to-point link, shared local area network (LAN), wide area network (WAN), or virtual private network (VPN) implemented over a public network such as the Internet. Each client may request the services of the storage system by issuing file-based and block-based protocol messages (in the form of packets) to the system over the network.
Many storage systems include an event monitoring system (EMS) that conveys appropriate system information and event notifications to system administrator and/or other interested parties, such as a vendor's customer support staff. As events occur within a storage system, the EMS logs the events in one or more event log files, which may then be utilized by the system administrator and/or customer support engineer to identify the cause of problems or to optimize system performance. A noted problem of such logging systems is that, the occurrence of events in the storage system typically generates a large volume of event messages that may be logged, some of which may be unimportant to the administrator using the system. As the number of unimportant messages that are logged increases, the size of the log files increases, which forces the administrator to sort through potentially thousands or tens of thousands of superfluous messages to find relevant log entries. Additionally, the storage space available for log files in the storage system may be limited. As such, as the number of messages being logged increases, the probability that the size of the log files exceed the space available increases. Furthermore, the log files may often be transmitted to a vendor for analysis after error conditions develop. Accordingly, as the size of the log files increase, there is a concomitant increase in transmission times and storage space requirements.
Certain event notification messages occur so frequently that they are deemed to be “chatter” and repeated logging of their occurrences wastes log space and complicates the administrator's ability to find relevant log information. Conventional UNIX-based event notification systems use a syslog program as an EMS perform limited suppression of such chatter messages. In such a conventional EMS, an event message is only suppressed if the same message occurs twice in a row; that is, if a chatter message is received twice in a row, only one instance is logged. However, if any message is received between the two chatter messages, then both chatter messages are logged. It is thus possible to have a situation where a plurality of chatter messages is intermingled with other messages such that no suppression occurs. Therefore, it is desirous to identify and suppress chatter messages to thereby limit the rate of growth of an event log file in a storage system.